1. Field of the Invention
The present invention relates generally to the allocation of resources in a computer operating system and particularly to an apparatus and method for overriding the resources allocated by the original operating system by providing a new resource map which takes precedence over the older resource map.
2. Summary of the Related Technology
In the past, operating systems were developed with a particular processor and hardware environment in mind. System designers enthusiastically tailored the operating system to take advantage of the underlying hardware. Unfortunately, these highly tailored operating systems were not portable. They fit the underlying processor so well that they would not run on another processor. This made the operating system inflexible. Thus, a new version of the operating system had to be coded and released for every new processor or hardware configuration change implemented.
In the past, computer designers, including third parties and original equipment manufacturers, were able to extend the functionality of an operating system software release by patching or implementing new functions. These functionally extensible patch files were sometimes referred to as "extensions." For example, to add a new functionality that allows an application program to play movies within a document, the system software would be functionality extended with an extension file. Extensions may also be referred to as "INIT" files because of their file type in the Macintosh computer environment provided by Apple Computer, Inc. Extension files were merely patch files that relied on the system boot routine to bring up the system from a power on reset state to a fully operational state.
Sometimes, it did not take long for the latest version of an operating system to be upstaged by a newer version generated to accommodate a new hardware configuration. Different versions of the same operating systems proliferated. While it is considered good programming design methodology to take advantage of the underlying hardware architecture, the underlying hardware architecture has in some instances created artificial limitations in the minds of the systems programmers. Typically, past operating systems that were designed to run on a particular hardware platform were incompatible with a different hardware platform, even though the two hardware platforms were very similar. Oftentimes the operating system designed to run on a first hardware platform would be prevented from loading onto a second slightly different platform because of a simple status check performed by the operating system during the boot procedure or system startup that prevented the software from loading. Thus, in order to change the operating system to accommodate the hardware environment, system designers had to release a new version of the operating system to accommodate the second hardware platform.
Frequently there were changes in hardware that required changes to the system software. In many cases, the changes were minor compared to the task of developing and releasing an entirely new version of the operating system software. Typically, in the past an entirely new version of the operating system software had to be developed for each set of machines. Each new set of machines thus required an individual development effort. These ad hoc efforts at system design negatively impacted engineering resources, quality control, marketing, and became somewhat of a nightmare for those attending to version control and documentation.
Moreover, customers are confused when numerous ad hoc versions of system software appear on the market with higher version numbers than the one they just bought. Customers often perceived a higher numbered version to be superior over a lower, numbered version, even though the difference in versions was only to accommodate hardware which the customer did not utilize. This contributed to customer dissatisfaction in some instances.
In addition, application programs that were written to run on a particular hardware platform may not be compatible with later versions of the hardware, because the hardware on the later version may not be identical to the particular hardware platform on which the application program was designed to run.
In the past, new functionality was typically added to operating systems with patch files. Patch files contained changes to system software that were called in and executed to augment system software after system initialization by the boot routine. These patch files would change code in the operating system to accommodate new machines, new hardware configurations, and to update system software in order to fix problems or add functionality after the release of a particular version of an operating system.
The named inventors herein have developed a new operating system architecture designed to solve these problems. Recent developments in computer operating systems architecture have moved portions of the boot or startup routine out of read only memory (ROM) and into resource files so that the boot routine is no longer hard coded and inflexible. Such an operating system is described in an application filed concurrently herewith, for a "A Method for Updating Computer Operating Systems to Control Later-Released Hardware Systems" by Chris Derossi and Dean Yu assignee. The details of that Computer Operating System Enabler are disclosed in that application, which is incorporated herein by reference, and therefore will not be repeated here. These new computer operating system architectures add a new dimension of flexibility to software upgrades. Thus there is a need for a new method and apparatus for resource allocation which is adaptable along with the new operating systems.